-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
matrix-synapse: 1.9.1 -> 1.11.1 #80447
Conversation
@GrahamcOfBorg test matrix-synapse postgresql |
I fixed pythonPackages.signedjson #80449, not sure if you just want to pull the changes into this pr or not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Anyone got an idea how this can be backported to 19.09 or any following release for that matter as we would add some changes to the postgresql module which might not be desired.
I'm actually using this on 19.09 already (my matrix HS is still running 19.09 on a custom branch based on EDIT: to clarify: synapse only refuses to start on fresh instances with wrong lc_ctype/lc_collate, existing databases remain usable (for now). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the short lifetime of 19.09 is actually an argument in favor of not backporting there, as the risk of breakage with a revert looks higher than the risk of breakage without a revert IMO
(however, I do think it totally makes sense to backport to 20.03, because even though we're technically past cut-off time, we haven't said it's stabilized yet, and the risk of breakage in the following 9 months is quite high, given we're speaking of synapse) |
Just for the record: we backported every release of matrix-synapse to stable in the past (at least since I'm taking care of the package) as many releases either contained important bugfixes or were needed due to some infrastructure changes at matrix.org that would break a self-hosted synapse otherwise. |
Please don't merge it yet. @florianjacob made some good suggestions about how we should document this and I'd like to add this (already started working on it) first :) |
1b06170
to
630e509
Compare
@GrahamcOfBorg test matrix-synapse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice documentation. Looks good to me.
* Linkify all service options used in the code-examples. * Demonstrated the use of `riot-web.override {}`. * Moved the example how to configure a postgresql-database for `matrix-synapse` to this document from the 20.03 release-notes.
630e509
to
849e168
Compare
Just pushed a change which fixes a minor typo in the docs. As soon as the eval is finished, I'll merge this now. The latest changes from Sunday were documentation-related (and reviewed by @mguentner), the actual update has been discussed pretty much now and should be mergable. Also, I'm running matrix-synapse 1.11.1 on NixOS 19.09 for a while now without any issues, the change should be fairly safe to use (and to backport). Thanks a lot for everyone involved here! |
Thanks for all your work on this @Ma27 🎉 |
Thanks to everyone involved, especially @Ma27 |
…B to be up Closes NixOS#236062 The PR NixOS#236062 was submitted because of the following problem: a synapse instance was running in a NixOS container attached to the host network and a postgresql instance on the host as database. In this setup, synapse connected to its DB via 127.0.0.1, but the DB wasn't locally set up and thus not configured in NixOS (i.e. `config.services.postgresql.enable` was `false`). This caused the assertion removed in this patch to fail. Over three years ago this assertion was introduced when this module stopped doing autoconfiguration of postgresql entirely[1] because a breaking change in synapse couldn't be managed via an auto-upgrade on our side. To make sure people don't deploy their DB away by accident, this assertion was introduced. Nowadays this doesn't serve any value anymore because people with existing instances should've upgraded by now (otherwise it's their job to carefully read the release notes when missing upgrades for several years) and people deploying fresh instances are instructed by the docs to also configure postgresql[2]. Instead, it only causes issues in corner cases like NixOS#236062, so after some discussion in that PR I think it's time to remove the assertion altogether. Also, there's no `Requires=` for `postgresql.service` in the systemd units which means that it's not strictly guaranteed that the DB is up when synapse starts up. This is fixed now by adding `requires`. To avoid being bitten by above mentioned cases again, this only happens if `config.services.postgresql.enable` is `true`. If somebody uses a non-local postgresql, but has also deployed a local postgresql instance on the synapse server (rather unlikely IMHO), it's their job to opt out of this behavior with `mkForce` (this is precisely one of the use-cases `mkForce` and friends were built for IMHO). [1] NixOS#80447 [2] https://nixos.org/manual/nixos/stable/#module-services-matrix-synapse
Could you please have a look at this PR #339195 ? I need some help since I haven't write a unit test for postgresql (especially in nixpkgs) before |
Motivation for this change
This updates
matrix-synapse
to 1.11.1.Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)